home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1994 February: Tool Chest / Dev.CD Feb 94.toast / Tool Chest / Development Platforms / Apple II / Essentials / Technical.Notes / UDsk / TN.UDSK.003 < prev    next >
Encoding:
Text File  |  1993-06-15  |  3.2 KB  |  73 lines  |  [TEXT/pdos]
  1. Apple II
  2. Technical Notes
  3. _____________________________________________________________________________
  4.                                                   Developer Technical Support
  5.  
  6.  
  7. UniDisk 3.5
  8. #3:    STATUS Call Bug
  9.  
  10. Revised by:    Matt Deatherage                                  November 1988
  11. Written by:    Mike Askins & Cameron Birse                     September 1984
  12.  
  13. This Technical Note documents a bug in the ProDOS STATUS call when used with
  14. a UniDisk 3.5.
  15. _____________________________________________________________________________
  16.  
  17.  
  18. The Bug
  19.  
  20. We have found that SmartPort does not return the WRITE PROTECT error on the 
  21. STATUS call.  (The WRITE call does return the WRITE PROTECT error as 
  22. required.)
  23.  
  24. The bug manifests itself under ProDOS (and not under Pascal, since Pascal does 
  25. not require the write protect error to be returned on the STATUS call).  
  26. Specifically, if a write-protected disk is present in the UniDisk 3.5, and the 
  27. application tries to write less than 512 bytes of data to a file that already 
  28. exists on the media, it becomes impossible to finish the write or to close the 
  29. file.  Many applications ignore errors on close calls and try to reuse the 
  30. buffer area which was presumably freed by the close call.  This reuse results 
  31. in further errors, even if the UniDisk 3.5 is later write-enabled, since 
  32. ProDOS still thinks the file is open.  This bug also decreases the maximum 
  33. number of open files allowed, as the file left open is included in that 
  34. number.
  35.  
  36. The bug also seems to cause the ProDOS CREATE call to fail.  When a new file 
  37. is created, opened and written to, and the write fails, the file manager does 
  38. not deallocate the block that it reserved in the creation attempt.  (The RAM 
  39. copy of the bitmap seems to get trashed--GET_FILE_INFO calls at this point 
  40. report that there are zero blocks available.)  If you subsequently write 
  41. enable the disk and do the save (with any size file), the file is written to 
  42. the disk, and the bitmap is updated.  The result is that there is a block 
  43. reserved on the disk that no file owns, and that block cannot be freed through 
  44. normal ProDOS file calls.
  45.  
  46.  
  47. The Solution
  48.  
  49. Although this problem was fixed in later IIc revisions, the UniDisk 3.5 
  50. interface for the Apple ][+ and IIe has never been modified.  Therefore, if 
  51. your application habitually performs the actions outlined above, you may avoid 
  52. it by first checking to see if the media is write-protected instead of letting 
  53. the buggy ProDOS STATUS call do it for you.
  54.  
  55. One way to accomplish this would be to issue a SmartPort STATUS call using a 
  56. statcode = $00.  This call returns four bytes of information, the first of 
  57. which is the general status byte.  This byte has the following format:
  58.  
  59. Bit   Meaning
  60.  7    0 = character device; 1 = block device
  61.  6    1 = write allowed
  62.  5    1 = read allowed
  63.  4    1 = device on line or disk in drive
  64.  3    0 = format allowed
  65.  2    0 = medium write protected (block devices only)
  66.  1    1 = device currently interrupting (Apple IIc only)
  67.  0    1 = device currently open (character devices only)
  68.  
  69. As shown in the table, bit 2 of this byte tells you what the ProDOS STATUS 
  70. call cannot seem to figure out--the media in the drive is currently write-
  71. protected.
  72.  
  73.